Initial Auth Next implementation in Soroban Host #645
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- Remove functions that are not anticipated to be used/useful with Auth Next (mostly account-related functions, as well as some unimplemented helpers) - Add `require_auth` function that is the entry point to Auth Next.
…for `AccountId` as host object.
This is the core of the Auth Next implementation. `AuthorizationManager` allows enforcing the authorization requirements or recording them, as well as performs authentication when needed, keeps track of the call stacks etc. Also added the built-in account 'contract' that handles authentication for the classic accounts. This is a contract just conceptually, it doesn't mean to support the actual contract interface.
- Added `require_auth` function and functions to support the recording mode and testing - Updated the public env interface according to the common env changes. - Removed network_passphrase in order to be more consistent with Core and remove some confusion around which one should be used
Currently this provides most of the coverage for Auth Next in Host. Testing this is quite tricky. As a followup and after the respective SDK updates we should add more tests that use non-built-in contracts with various deep invocation trees, multiple accounts etc.
|
Build is supposed to be failing until the XDR changes are merged and pinned here. |
sisuresh
reviewed
Feb 1, 2023
sisuresh
reviewed
Feb 1, 2023
- Store recording mode tracker pointers in rollback snapshots - In tests, reset the whole `AuthorizationManager` instead of relying on cleaning up/storing individual fields
sisuresh
approved these changes
Feb 2, 2023
sisuresh
reviewed
Feb 3, 2023
sisuresh
reviewed
Feb 3, 2023
paulbellamy
pushed a commit
to stellar/stellar-cli
that referenced
this pull request
Feb 6, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What
This is the initial implementation iteration of the Auth Next proposal.
This is based on the XDR changes (to be merged) from stellar/stellar-xdr#65
On a high level, this PR introduces the following:
Addresshost object type that can be used to represent either classic Stellar accounts or generic contract-based account. This replacesAccountIdandIdentifiertypes, as well asinvoker/source_accountetc. in the public interfaces.Addresscan be passed around via contract interfaces, used in the data storage keys, as well as used in authorization flows.require_authhost function that enforces an authorization of the current contract call from the givenAddress. The authorization data with the corresponding signature(s) is passed along with the contract invocation transaction.require_authisAuthorizationManager(auth.rs) that keeps track of the call stacks to provide the proper signature context, ensures that authorizations aren't reused, and performs authentication using the proper account contract. It also has a recording mode that allows to recordrequire_authcalls with the context instead of enforcing them.Why
The Auth Next motivation is in the proposal. The general idea is that we want to provide a protocol-defined support for generalized authorization of nested contract invocations, customizable authentication via account abstraction and structured signatures payloads that allow for better wallet integration.
Known limitations
This does some foundational work on Auth Next, and followups of various scope are required. Some notable followups are:
check_authto allow for safe ledger writes, allow only self-reentrance, maybe update interface etc.)